IBIS Macromodel Task Group

Meeting date:01 June 2021

Members (asterisk for those attending):
Achronix Semiconductor        Hansel Dsilva
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                              Ken Willis
                              Jared James
Google:                       Zhiping Yang
Intel:                        Michael Mirmak
                              Kinger Cai
                              Alaeddin Aydiner
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
                            * Ming Yan
                              Todd Bermensolo
                            * Rui Yang
Luminous Computing          * David Banas
Marvell                       Steve Parker
Micron Technology:            Randy Wolff
                            * Justin Butterfield
Missouri S&T                  Chulsoon Hwang
Siemens EDA (Mentor):       * Arpad Muranyi
SiSoft (Mathworks):         * Walter Katz
                              Mike LaBonte
Teraspeed Labs:             * Bob Ross
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:
  
- None.

-------------
Review of ARs:

- Walter to add diagrams for the normal reference flow and send out
  BIRD211.2_draft9.
  - Done.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the May 25th
meeting.  Ambrish moved to approve the minutes.  Walter seconded the motion.
There were no objections.

-------------
New Discussion:

BIRD211.2 draft 9:
Arpad noted the email he had sent summarizing the state of the discussions.  He
said he thought that as discussions went on, we kept forgetting about some of
our requirements.  This led us to keep going around and around.

Arpad repeated the two requirements he had observed and noted in his email:
#1:  No changes should be required for terminal models (initial Tx and final Rx)
#2:  We should be able to use the same Tx and Rx models as terminal models and
     as Redriver models.
     
Ambrish said a model could satisfy #2, but he wasn't sure we needed to mandate
it.  Fangyi said #2 was really a side effect of Walter and Radek's goal to have
the same specifications for a terminal Tx or a Redriver Tx.  Radek said the
original point was that they didn't want to have a special type of Tx that is
for Redrivers only (which would have been the case if Tx_Impulse_Input were only
allowed for Redriver Tx models).  In the BIRD as written, the Redriver Tx would
be included in a [Repeater Pin] keyword, but that does not prohibit the same
model from being used as a terminal Tx as well.  Fangyi said the specification
should allow #2 but not require it.  The group agreed with this, and the group
accepted both of the requirements Arpad stated.  Walter said he would add them
to the Solution Requirements section of the BIRD, per Arpad's suggestion.

Walter referred to his email in reply to Arpad's email on the state of the
discussions.  He said a model should represent in simulation what the hardware
does.  Ambrish objected that this requirement would mean there could be no such
thing as a statistical model.  Walter said he meant the model should represent
what a device does in hardware, not necessarily emulate how it does it.  A model
could provide extra features not found in the hardware in order to help with
making engineering decisions.  For example, a Tx model might provide adaptation,
but if the hardware didn't then the Tx model should also provide a mode without
adaptation that simply uses specified tap coefficients.  For another example, a
memory vendor's actual DDR5 Rx hardware would not have the ability to optimize
itself, but the model could provide an option to adapt to help the system
designer make engineering decisions.  But, such a model should also provide a
fixed mode that does not adapt.  Ambrish said this was veering into a discussion
of what is a good model and what is a bad model.  He said this discussion could
be endless, and the specification should simply define the API and not go into
what constitutes a "good" model.

Walter said he was trying to correct a mistake he thought we had made 12 years
ago.  He said with IBIS 7.0, there's no way for a model maker to state whether
their Tx model is adapting or not (meaning there's no Reserved Parameter that
allows the model maker to advertise the behavior).  Ambrish said there was no
reason that the tool needed to know this information given the IBIS 7.0 flows.
Walter said that if Tx_Impulse_Input can be used for all Txs, then it provides
the way for model makers to advertise this behavior for AMI 7.1 Tx models.

Because there was some confusion, Walter addressed the parameter example he
had given at the end of his email.  He said that he had provided an example
of a possible solution if Tx_Impulse_Input had been restricted to Redrivers.
His example showed the parameter renamed to include "Redriver" in the name.
It also showed an additional parameter (Tx_Adapts), which could have been
introduced and used with terminal Tx.  However, since we agreed that
Tx_Impulse_Input can apply to all Txs, this example is not necessary.

Ambrish said he was concerned about mission creep.  He said the name of the BIRD
was "New Redriver Flow".  Walter agreed that it was a bit of mission creep, but
since Tx_Impulse_Input gives the model maker a way to specify that their
Redriver Tx does or doesn't optimize, why not extend that to regular Txs too?
If the Tx_Impulse_Input can apply to all Txs, then we've given the model maker a
way to specify whether or not their Tx optimizes.

Arpad returned to his original summary and the two requirements we'd agreed
upon.  He said these requirements mean we can't go with Bob's earlier proposal
to limit Tx_Impulse_Input to repeaters.  Bob agreed and said the straw vote at
last week's meeting resolved that we weren't restricting it to repeaters.  He
said Walter had instead added some new figures for the normal flow and made
the BIRD a bit more broad.  Bob noted that he had been taking the name of the
BIRD literally ("Redriver") when making his first proposal.  He said it's now
effectively defining new flows altogether.  Walter agreed that the title of the
BIRD could be changed.

Walter said he'd added new block diagrams depicting the normal (single-channel)
flow given the various settings of Tx_Impulse_Input for the Tx.  He had also
added new text to describe the flows and block diagrams.  However, he had not
actually changed the simulation flow.  Arpad said his understanding was that
changes in the descriptions of the flows, other than the Redriver flow that is
being fixed, were only made to incorporate this new parameter that could now
appear.  But the flows themselves were not changed.

Walter reviewed his diagrams and proposed new text for the single-channel
reference flow.  Bob and Ambrish suggested removing all language related to
versions, e.g., "documented in IBIS 7.0" or "AMI Version 7.1 and later...", etc.
The group agreed.  All such language was removed, and the various flows were
tied to whether or not Tx_Impulse_Input was specified and what its value was
if it was specified.  Radek suggested naming the three different flow options
Flow 1, Flow 2, and Flow 3 and referring to them that way to be precise.  Walter
agreed and said he would add those names to the block diagrams too.

Ambrish said we should be careful to distinguish between the statistical and
time domain flows.  Walter noted that his rewrite had introduced the term
"initialization flow", after which you could then proceed with statistical or
time domain simulation.  He said he thought it resulted in an improved
description of what Init and GetWave do.  He asked people to read it carefully
and comment.  Arpad said he thought we were finally down to wordsmithing and had
moved beyond technical flow questions.

- Curtis: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.

AR: Walter to send out BIRD211.2_draft10 with today's changes.

-------------
Next meeting: 08 June 2021 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
